Skip to content

Initial app bootstrapping with cookie cutter. Support for basic routing + Request object #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 17 commits into from
Jan 24, 2020

Conversation

mscosti
Copy link
Contributor

@mscosti mscosti commented Oct 14, 2019

I finally might have some time for projects and wanted to get the ball rolling here on this library.

This is 99% Generated from the Cookie Cutter project, following the learn guide for what parameters I should be using. Please let me know if I misunderstood any of the parameters, especially around attribution.

The other 1% is an incredibly pared down version of this example from the ESP32SPI lib, just to kick things off. I picture for some foreseeable time the library code and API will be in flux to allow for quicker development and changing ideas until we land in a spot where we all feel comfortable with the API and structure.

Update:

I've been working on this against my own fork on and off for the past month, so this PR now includes not only the cookie cutter output, but also some new library code that should make handling incoming requests easier.

Features:

  • Request handlers are passed a higher level Request object to represent the current incoming request, instead of the raw WSGI environ dictionary. See request.py to see extracted properties
  • Routing with a the @route decorator
    • Annotate a method with the url path you want to activate when called, and optionally a list of HTTP request methods the route should match for. If method list empty, default to [GET]
      •  web_app = WSGIApp()
         @web_app.route("led_off") // GET <ip>/led_off
          def led_off.....
        
         @web_app.route("led_on", ["POST"]) // POST <ip>/led_on
         def led_on .....
        
    • Routes can include path parameters, using the syntax "<param>", and will parse out the param and pass it to your request handler
      •  @web_app.route("/led_on/<r>/<g>/<b>") // GET <ip>/led_on/255/0/255
          def led_on(request, r, g, b) ....  // r, g, b will be strings "255", "0", and "255"
        

Add pared down version of wsgi application from esp32 example to start
@ladyada
Copy link
Member

ladyada commented Oct 14, 2019

hiya i dont think ya wanna be committng the docs folders, thats generated for you by sphinx (i think?)

@mscosti
Copy link
Contributor Author

mscosti commented Oct 14, 2019

Yeah, I just noticed that as well. It looks like I'm missing some files from cookie cutter (like a .gitignore). Looking into that now. I Installed it from pip, do you know if the latest build is available there? cookiecutter -V is saying I have version 1.6.0

@ladyada
Copy link
Member

ladyada commented Oct 14, 2019

@ladyada
Copy link
Member

ladyada commented Oct 14, 2019

@brentru
Copy link
Member

brentru commented Oct 14, 2019

@mscosti You may want to test this (and your code in ESP32SPI, too) with the latest version of nina-fw (v1.4.0) on your ESP32.

We've updated the ESP-IDF version which builds nina-fw using ESP-IDF v3.3 (we were previously using ESP-IDF v3.2).

@mscosti
Copy link
Contributor Author

mscosti commented Oct 14, 2019

Looks like I accidentally deleted all the dot files after running cookie cutter, d'oh!

  • Re ran cookie cutter to get the following files back: .gitignore, .pylintrc, .readthedocs.yml, and .travis.yml

  • Also removed the generated _build folder from docs.

  • Look into travis

@brentru Neat! I Will look into upgrading firmware soon, happy to see the guide has been updated to include instructions for external breakout boards :)

@mscosti
Copy link
Contributor Author

mscosti commented Oct 19, 2019

@brentru Upgraded firmware on my pyPortal to v1.4 and tested it with no issues on new firmware.

I also added a starter basic simpleTest example.

I think it might be good to go to at least start us off, pending any other comments. @ladyada @brentru

@siddacious
Copy link
Contributor

@mscosti I'll take a look at this tomorrow

Add in Route Decorator for registering request handlers
* Fix case where variable part of path would match with 0 characters as value instead of requiring minimum of 1
@siddacious
Copy link
Contributor

@mscosti I copied your fork over to my Metro M4 + Airlift shield, along with a fresh copy of Adafruit_CircuitPython_ESP32SPI and get the following output and error when trying to run the example application. Looking at the code I'm honestly unsure what it's complaining about; as far as I can tell you're just setting an instance attribute?

It's been a while since I worked with this code so it's entirely possible that I'm overlooking something or set up something incorrectly.

image

@mscosti
Copy link
Contributor Author

mscosti commented Nov 15, 2019

thanks for giving it a try! were you in this branch or my master branch? my master branch has some more development done that will be in a future PR. ill plan on looking into reproducing this error this weekend.

@mscosti mscosti changed the title Initial app bootstrapping with cookie cutter Initial app bootstrapping with cookie cutter. Support for basic routing + Request object Nov 17, 2019
@mscosti
Copy link
Contributor Author

mscosti commented Nov 17, 2019

@siddacious @brentru @ladyada Updated PR to include more work than just cookie cutter output. Now includes some of the features I've been working on on and off over the past month.

@siddacious Thanks for testing! There a few bugs with the Request object that I have since resolved.

@kattni
Copy link
Contributor

kattni commented Jan 8, 2020

@siddacious @brentru Can one of you follow up with testing this again with the final updates? It's passing otherwise and may be ready to merge.

@siddacious
Copy link
Contributor

@mscosti @kattni I pushed an update to the compare branch to add the rest of the actions changes. I can test tomorrow if need be but from my vantage it's ready to merge

@siddacious
Copy link
Contributor

siddacious commented Jan 10, 2020

@mscosti when doing the actions patch, I noticed that I was indeed on the master branch when testing which was likely the source of my issues. If you think it's ready to go, go ahead and merge if you have the right permissions. If not, @ me and I'll do it

@mscosti
Copy link
Contributor Author

mscosti commented Jan 12, 2020

@siddacious Doesn't look like I have merge permissions to this repo, so if its working for you, I think its probably worth merging to have the groundwork in place to support future additions.

@siddacious siddacious merged commit 5b6e870 into adafruit:master Jan 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants